![]() |
|||
![]()
|
![]() |
![]() Click Here! |
![]() |
Notice in the previous paragraph that I said the WINSOCK.DLL files are tied to the TCP/IP software underneath them. That is what the specification calls for: TCP/IP network transport software. After all, the group at the BOF all wrote TCP/IP protocol stacks and applications. Novell was a part of that meeting, but only to represent the LAN WorkPlace TCP/IP software products they gained when they bought Excelan in 1989. Companies interested in providing TCP/IP access to IPX clients came up with a clever idea: use the specified WinSock API, but split the WinSock into two pieces. The client WinSock piece speaks IPX/SPX, since thats the standard protocol NetWare clients have available. The server WinSock piece speaks IPX/SPX at the top, to communicate with the client, and TCP/IP at the bottom, to communicate with the gateway server host software. The gateway server software can reside on a variety of different platforms. NetWare servers are a good place, of course, since they already speak IPX/SPX and have a good TCP/IP protocol stack available. Windows NT stations are popular for the same reasons, and some companies make turnkey hardware/software units that sit on the network. The bottom part of the client WinSock software runs on this server, hidden within the gateway server software. Vendors have three components to arrange in traditional WinSock:
How do you split these choices across a network? Obviously, the Windows- specific extensions will stay in the PC client software. The IPX/SPX stack used by NetWare clients must be converted to TCP/IP in the gateway, and may handle the socket and database routines locally (at the client) or remotely (at the gateway). This choice is often dictated by how much control the NetWare to Internet gateway vendor has over the TCP/IP stack. Some gateway vendors control their own gateway, including the protocol stack in the gateway. Other gateway vendors use existing machines (such as NetWare servers or Unix hosts) as gateways, and must rely on the TCP/IP stack resident in the gateway host. Locally-converted functions place less stress on the gateway, while remotely-converted functions place less strain on the client. The good news is that even the slowest NetWare to Internet gateway product will perform faster than any WAN connection of T1 speeds (1.544Mbps) or less. Only when the other side of the IPX to TCP/IP conversion runs at near-Ethernet rates does any performance variation appear. IPX/IP GATEWAY INSTALLATION AND CONFIGURATION The only prerequisite for the IPX/IP Gateway is to have TCP/IP enabled on the host server. Before going further, verify that TCP/IP is active on the server, and that TCP/IP systems can ping the server, and the server responds. If that doesnt work, your gateway wont either. IntranetWare includes the IPX/IP Gateway on the CD-ROM disk labeled, cleverly enough, Internet Access Server. Although supposedly an internal code name only, the term NIAS (Novell Internet Access Server) shows up all over the disks and documentation. There are more services than just the IPX/IP Gateway, but lets concentrate just on the gateway for now. Novells Border Manager includes a slightly improved IPX/IP Gateway, but the installation and configuration is similar enough well just talk about IntranetWare. Start at the server console (or RCONSOLE) and type LOAD INSTALL.Check for Products to install, and choose a product not listed. Refer the system to the CD-ROM drive, and load the IPX/IP Gateway from there. If the system asks if you with to install previously-configured routing information, just say NO. Your license diskette will be required, so have it close at hand. The LOAD IPXIPGW command will be added to your AUTOEXEC.NCF file during installation. IntranetWare uses the INETCFG utility to enable the IPX/IP Gateway, but not the newer version that ships with BorderManager. If you install the IPX/IP Gateway during the BorderManager installation, it is active when loaded. If you are running the IPX/IP Gateway that came with IntranetWare, go to INETCFG and choose Protocols, then TCP/IP. Near the bottom of the screen is the IPX/IP Gateway Configuration field, currently disabled. Highlight that field, press Enter, and choose Enabled. Save your work, just like all smart computer people. If you are running the IPX/IP Gateway that came with BorderManager, you now know that NetWare/IP must be running, you must install the NIAS bundle, but you dont enable the IPX/IP Gateway at the server console - you do it through NWAdmin. There are two steps to complete before you can activate the Gateway. First, NWAdmin must be used at least once before adding the Gateway installation snapins. If your network is an active network, you will have used NWAdmin plenty. If your network is brand new, execute NWAdmin once to the point of expanding and contracting some of the containers and checking the details of a user or two. That will be plenty to tell the operating system the program has been used. Second, you must run \PUBLIC\BSSNAP\W95\SETUP.EXE from the Windows 95 workstation used as your management station. The BSSNAP subdirectory is installed during the IPX/IP Gateway installation process, although the installation screens didnt tell you that. SETUP.EXE adds some extra command buttons to NWAdmin for the server acting as host for the IPX/IP Gateway. Take a look at Exhibit 4-3-1, showing the Border Services Setup page within NWAdmin. You can see in the background dialog that the IPX/IP Gateway is enabled here, as well as several other new features available in the BorderManager suite. More to the point now, however, notice how I am setting the IP address for the IPX/IP Gateway in the foreground dialog. This must match the IP address used for the TCP/IP-enabled segments of the host server. Checking Both under Usage Type allows the IPX/IP Gateway to direct clients toward the Internet and your internal intranet, or limit access to the network you desire.
|
![]() |
|
Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details. |